home *** CD-ROM | disk | FTP | other *** search
/ Tricks of the Mac Game Programming Gurus / TricksOfTheMacGameProgrammingGurus.iso / Information / Stuart's Tech Notes / ScrollRect dos and don'ts < prev    next >
Encoding:
Text File  |  1995-06-14  |  2.6 KB  |  47 lines  |  [TEXT/ttxt]
  1. (C) August 1993 Stuart Cheshire <cheshire@cs.stanford.edu>
  2.  
  3. Don’t use ScrollRect on offscreen GWorlds; it is slower than the equivalent CopyBits call, and doesn't work properly on systems with more than one monitor. I wasted a lot of time tracking down this bug.
  4.  
  5. Even if you personally don't have more than one monitor, an increasing number of people do, especially with the new PowerBooks which, out of the box, will drive both the internal display and an external colour monitor simultaneously.
  6.  
  7. To understand the bug, first understand the cleverness of ScrollRect.
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17. Imagine you scroll an image ten pixels up and ten pixels to the right. This leaves an empty white 'L' shaped region below and to the left of the scrolled area. Now imagine that the image is in a window which straddles two monitors, a colour monitor on the left and a monochrome one on the right.
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29. It doesn't make sense to scroll black and white pixels across the boundary line onto the colour monitor, so ScrollRect effectively does a separate scroll for each monitor, resulting in two different empty white 'L' shaped regions. The updateRgn returned by ScrollRect is the union of these two regions, so you can simply pass it to InvalRgn and the correct areas of the window will be added to the updateRgn for redrawing on the next 'update' event. Marvelous!
  30.  
  31. However, now suppose that you are using ScrollRect to move pixels around on an off-screen GWorld. ScrollRect doesn't realize that an off-screen GWorld is not on the screen, and performs its normal cleverness regarding not scrolling pixels across the boundary between two monitors. Of course, there are no boundaries on the off-screen GWorld, but if you imagine super-imposing your monitor layout on top of your off-screen GWorld's coordinate system, then your image will develop 'tears' wherever it crosses a line corresponding to the boundary of two monitors on your desktop.
  32.  
  33. So, the moral is, when you are scrolling the contents of a *window* (in response to the user clicking the scroll bars), and you want the correct updateRgn afterwards so that the window will automatically redraw correctly, then ScrollRect will nicely cope with multiple monitors for you, but for other cases use CopyBits.
  34.  
  35. In case it is not obvious, here is the translation of the ScrollRect call:
  36.  
  37. Old ScrollRect way:
  38.     SetGWorld(myGWorld, NULL);
  39.     ScrollRect(&theRect, distHoriz, distVert, updateRgn);
  40.  
  41. New CopyBits way:
  42.     BitMap *pixmap = (BitMap*)*GetGWorldPixMap(myGWorld);
  43.     Rect destRect  = pixmap->bounds;
  44.     OffsetRect(&destRect, distHoriz, distVert);
  45.     SetGWorld(myGWorld, NULL);
  46.     CopyBits(pixmap, pixmap, &pixmap->bounds, &destRect, srcCopy, NULL);
  47.